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(57) Abstract: A method for sending a data packet (DP), 
which directly or indirectly indicates a quality -of-service 
requirement (QoS), to a mobile node (MN) from a 
correspondent node (MCN) via a multi -bearer network, or 
MBN, which provides at least one interface unit (IU) to each 
of multiple alternative bearer networks (BN) between the 
MBN and the mobile node. The method comprises selecting 
an optimal bearer network (BN) for sending a data packet 
(DP) between the MBN and the mobile node (MN) based on 
1) the quality -of-service requirement (QoS) of the data packet 
(DP) in question; 2) traffic data load data (41) related to the 
multiple bearers; 3) interface unit preference information 
(PIU, 42); and 4) bearer type preference information (PBT, 
43). 
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Packet routing in a multi-bearer-type network 

BACKGROUND OF THE INVENTION 

The invention relates to traffic management in a multi-bearer packet 
data network. A multi-bearer network, or an MBN, is a network having the ca- 
5 pability to carry a data packet via one of several alternative bearers. To be 
more precise, the term 'multi-bearer network' should be interpreted as mean- 
ing 'multi-bearer-type network', or in other words, a network arrangement 
which provides multiple different bearer types for data packet delivery. An ex- 
ample of a suitable MBN is a concept known as MEMO (Multimedia Environ- 

10 ment for Mobiles), see reference 1. Additionally, the MBN supports mobility of 
a subscriber terminal. An example of terminal mobility is IP mobility, which is 
the topic of standard RFC2002 by the Internet Engineering Task Force (IETF). 
This RFC standard is incorporated herein by reference. 

The problem underlying the invention is how to select the optimal 

15 bearer for each data packet in varying situations in a multi-bearer network. 
Data packets have different quality-of-service requirements. Situations may 
vary because the subscriber moves or the network load changes. 

BRIEF SUMMARY OF THE INVENTION 

Accordingly, it is an object of the present invention to provide a 

20 mechanism for selecting the optimal bearer for each data packet in varying 
situations. The object is achieved by a method and equipment which are char- 
acterized by what is disclosed in the attached independent claims. Preferred 
embodiments of the invention are disclosed in the attached dependent claims. 
The invention is based on the idea that selecting the optima! bearer for a data 

25 packet between the MBN and the mobile node is based on a combination of 1) 
the quality-of-service requirement (traffic class) of the data packet in question, 
2) the mobility data related to the mobile node, 3) the traffic data related to the 
multiple bearers, and 4) bearer preference information. The bearer preference 
information can be obtained from the mobile node, and optionally, from the 

30 operators of the home and visited MBN operators. 

In order to save the battery of a portable mobile node, it is prefer- 
able that the mobile node only monitors one bearer type (network) at a time. 
For example, the subscriber data related to the mobile node can include a 
default bearer type, such as GSM or UMTS. The mobile node should be 

35 paged on this bearer. The mobile node can be ordered to monitor the selected 
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bearer type by sending a modified page message which indicates the selected 
bearer type, channel, possible decryption data, etc. Alternatively, such infor- 
mation can be sent in a separate message, such as a short message, USSD, 
(Unstructured Supplementary Service Data), data call or the like. 
5 According to another preferred embodiment of the invention, as 

long as the mobile node is within a certain coverage area, all IP packets be- 
longing to the same session (or flow if flow labels are used) are routed via the 
same interface unit. For example, if a mobile node is receiving IP packets from 
a DAB network, via a cell x, all IP packets of the same session should be 
10 routed via DAB cell x, unless the mobile node moves out of the coverage area 
of this cell. 

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING 

The method and the apparatus according to the invention will be 
described in more detail by means of preferred embodiments with reference to 
15 the appended drawing in which: 

Figure 1A shows a preferred structure of a network arrangement in 
which the invention can be used and the available options for mobile node- 
terminated (downlink) traffic; 

Figure 1B shows the available options for mobile node-originated 
20 (uplink) traffic; 

Figure 2 shows the major functional blocks of a visitor administra- 
tion system according to the invention; 

Figures 3A and 3B show the internal structure of the visitor admini- 
stration system VAS in more detail; 
25 Figure 4 illustrates the cooperation between a traffic management 

unit TMU and a traffic distribution unit; and 

Figure 5 shows a preferred feature of the invention which relates to 
broadcast networks; and 

Figure 6 shows a preferred version of a routing table with two op- 
30 tional fields. 

DETAILED DESCRIPTION OF THE INVENTION 

Figure 1A shows a preferred structure of a network arrangement in 
which the invention can be used. A mobile node MN communicates with its 
correspondent node MCN via a multi-bearer network MBN which offers several 
35 alternative bearers for a data packet DP. Each data packet comprises a 
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header H and a payload part PL. To be precise, a data packet typically has 
several headers inside each other, because each protocol layer inserts its own 
header. However, each protocol layer only handles each own header, and a 
model with only one network layer header is usually sufficient for describing 
5 the invention. The header indicates, directly or indirectly, a quality-of-service 
requirement QoS for the data packet. An example of a direct QoS indication is 
a case where the data packet header includes a parameter which is or which 
can be directly mapped to a quality-of-service requirement parameter. An ex- 
ample of an indirect QoS indication is a case where the header indicates a 

1 0 PDP (packet data protocol) context, and the PDP context in turn indicates the 
QoS requirement. It should be understood, that 'quality of service' is a very 
generic term indicating certain requested or negotiated transmission charac- 
teristics, such as bit rate, maximum delay and/or packet loss probability. De- 
pending on the actual protocol used, quality of service is indicated by or 

15 mapped to one of the existing appropriate fields, such as the Preference field 
of IPv6 or the Type of Service of IPv4. The term 'traffic class' is used to refer 
collectively to the fields which are used to indicate the quality-of-service re- 
quirement. 

In Figure 1 A, it has been assumed that the MBN communicates with 

20 the MCN via the Internet There is preferably a firewall FW at the edge of the 
MBN. A gateway node GW interfaces the MBN to the Internet. A backbone 
network BBN combines the different bearer networks BN. It may be the MBN 
operator's internal network. A physical example of a BBN is a high-speed lo- 
cal-area network or a wide-area network. A home administration system HAS 

25 is largely equivalent to a home agent in the IP mobility scheme (described in 
the RFC 2002). A visitor administration system VAS is a logical extension of a 
foreign agent in the IP mobility scheme. The MBN has access to several bear- 
ers for conveying the data packet to the mobile node MN. 

The bearers include a first set of bidirectional bearers. Examples of 

30 bidirectional bearers are circuit-switched mobile networks, such as GSM 
(Global System for Mobile communications), and packet-switched mobile net- 
works, such as GPRS (General Packet Radio Service), and third generation 
mobile networks, such as UMTS (Universal Mobile Telecommunications Sys- 
tem), which offer both circuit-switched and packet-switched bearers. For each 

35 bidirectional bearer, there is a corresponding interface unit GSMJU, GPRSJU 
and UMTS IU. 



JSOOCID: <WO O150790A1_L> 



WO 01/50790 




PCT/FI00/01166 



4 

The bearers include a second set of unidirectional bearers. Exam- 
ples of unidirectional bearers are digital audio broadcast (DAB) and digital 
video broadcast (DVB). For both DAB and DVB, Figure 1 shows two cells 
DAB_C1, DAB_C2; DVB_C1, DVB_C2, and their corresponding interface units 
5 DABJU1, DABJU2; DVBJU1, DVBJU2. 

In the system of Figure 1, there is another difference between the 
first and second set of bearers. In addition to being bidirectional, the bearers of 
the first set are point-to-point bearers. In other words, each connection is cus- 
tomized to one particular recipient. In contrast, the bearers of the second set 

10 are broadcast or multicast bearers. In other words, it is not immediately appar- 
ent how a connection can be customized to individual recipients. One solution 
to this problem is encryption of the broadcast/multicast bearers with distribu- 
tion of decryption keys only to the intended recipients. 

Within the context of this application, 'uplink' means from the mobile 

15 node MN to the correspondent node MCN and 'downlink' means the inverse 
direction. The bold arrows in Figure 1 depict various routing options for data 
packets in the downlink direction. For the span 12 between the MCN and the 
VAS, data packets are routed directly if the IP address of the mobile node MN 
(or its subscriber) does not belong to the MBN network. If the IP address be- 

20 longs to the MBN network, data packets are routed via the home administra- 
tion system HAS. This route is drawn with a thin dotted line 11. For the span 
12 between the VAS and the MN, the VAS has several alternative bearers. 
According to the invention, the VAS considers ail of the following: 1) the qual- 
ity-of-service requirement (the traffic class) of the data packet in question, 2) 

25 the mobility data related to the mobile node (i.e., which bearers and which in- 
terface units can be used to reach the MN), 3) the traffic load/resource avail- 
ability data related to the multiple bearers, and 4) bearer preference informa- 
tion. The optimal bearer selection and the internal structure of the VAS will be 
described later in more detail. 

30 Figure 1B shows the available bearer options for uplink traffic be- 

tween the MN and the MCN. Because the DAB and DVB bearers are unidirec- 
tional (downlink only), they are not available for uplink traffic, and the only 
available bearers 21a to 21c are via the mobile networks GSM, GPRS and 
UMTS. 

35 Figure 2 shows the major functional blocks of a visitor administra- 

tion system VAS according to the invention. The VAS has three main functions 
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or sections: 1) a mobility management function MMF, 2) a traffic management 
function TMF, and 3) a caching proxy CP. The mobility management function 
MMF of the VAS is largely equivalent to a foreign agent in the IP mobility 
scheme of RFC 2002. The MMF may also participate in authentication and/or 
5 charging. The functions of the traffic management function TMF include a) 
collecting traffic information from the various bearer networks (GSM, GPRS, 
UMTS, DAB, DVB...), b) collecting traffic management-related information 
from the mobile node MN and its home MBN, c) sending traffic management- 
related messages to the mobile node MN, d) selecting the bearer network for 

10 downlink traffic, and e) forwarding downlink traffic to the selected bearer net- 
work. The function of the caching proxy CP is to maintain frequently-requested 
content in high-speed memory in order to minimize retrieval of such content 
over telecommunication lines. The caching proxy CP should have enough in- 
telligence to handle data packets in an application-specific manner, instead of 

15 merely caching IP traffic packets. 

Figures 3A and 3B show the internal structure of the visitor admini- 
stration system VAS in more detail from the point of view of traffic manage- 
ment. Figure 3A shows the VAS structure from the point of view of user traffic. 

IP Routing Software blocks 31 to 33 route data packets to the ap- 

20 propriate recipients, based on the packet headers. These blocks also decap- 
sulate IP packets towards the VAS and pass the decapsulated packets to the 
upper layers for further processing. Correspondingly, the blocks 31 to 33 also 
encapsulate packets arriving from the upper layers. In Figures 3A and 3B, the 
packets from the upper layers are indicated as the traffic flow entering the 

25 blocks 31 to 33 from above. The VAS also comprises a traffic distribution unit 
TDU. The function of the TDU is a) to determine the traffic class of incoming IP 
packets based on one or more quality-of-service related parameters indicated 
by the packet header (these parameters may comprise 'type of service' for 
IPv4 and 'preference* or 'flow label 1 for IPv6), b) based on the traffic class/QoS 

30 requirement, to select an appropriate bearer (radio network) for downlink traf- 
fic, and c) to encapsulate each IP packet into an outer IP header towards the 
selected bearer network and interface unit. The fact that the arrow from the 
TDU enters IP routing block 32 from below indicates that the TDU has already 
encapsulated the IP packets, and the block 32 should not perform another en- 

35 capsulation. 
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Figure 3B shows the VAS structure from the point of view of system 
traffic, mobility management and traffic management. A mobility management 
unit MMU performs the functions which are normally performed by a foreign 
agent in an IP network with mobile IP support, with some enhanced function- 
5 alrty related to MBN support, such as cell selection and handover control 
within a broadcast network or between networks. The function of the traffic 
management unit TMU is a) to collect traffic load information from the various 
bearer networks BN (DVB, DAB, UMTS P etc.), b) to collect and to update (via 
the MMU) bearer preference information from the mobile nodes, c) optionally 

10 to collect bearer type preference information from the home network of each 
mobile node, d) to create and update bearer routing information to the TDU, 
and e) to send traffic administrative messages to the mobile nodes. For per- 
forming these functions, the traffic management unit TMU receives the follow- 
ing input: a) traffic load information from the various bearer networks BN, b) 

1 5 bearer preference information from the mobile nodes, and c) optionally bearer 
type preference information from the home MBN of each mobile node. The 
traffic distribution unit TDU and the traffic management unit TMU cooperate to 
perform the traffic management function TMF shown in Figure 2. The coop- 
eration of the TDU and the TMU will be described in more detail in connection 

20 with Figure 4, 

Figure 4 illustrates the cooperation between the traffic management 
unit TMU and the traffic distribution unit TDU. The traffic management unit 
TMU considers three kinds of information: 1) traffic load information 41 from 
the various bearer networks BN, 2) available interface unit information 42 and 

25 3) preferred bearer type 43. The traffic information 41 from the various bearer 
networks BN indicates the load (or inversely: the available capacity) on the 
alternative bearer networks. This information may be used as a basis for hard 
decisions (whether or not a requested bearer can be allocated) or for soft de- 
cisions (whether or not tariffs should be adjusted to promote the use of lightly 

30 loaded bearer networks). The available interface unit information 42 can be 
generated as follows. A preferred interface unit table PIU indicates for each 
bearer type (DVB, DAB, UMTS, GPRS and GSM) one or more preferred in- 
terface units (or to be more precise the IP addresses of the preferred interface 
units) and their rank of preference. The PIU table is mobile-node-specific. 

35 Each mobile node MN should directly or indirectly indicate its PIU table during 
registration and in connection with location updates. For example, an MN may 
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indicate the PIU directly by forming and sending the PIU table to the VAS. The 
PIU table is not sent to the TMU directly, however. Instead, the mobility man- 
agement unit MMU controls handover within and between the networks. Ac- 
cordingly, the MMU also selects the interface unit for each broadcast network. 
5 The MMU considers the PIU and the mobility data related to the mobile node 
(i.e., what interface unit can be used to reach the MN). The MMU uses this 
information to create an available interface unit table AIU which is then applied 
to the TMU (instead of the PIU table as such). The preferred bearer type in- 
formation 43 can be organized as a table of a preferred bearer type PBT. The 

10 PBT table indicates, for each traffic class, several alternative bearer types with 
decreasing preference. The acronym 'WLAN 1 stands for wireless local-area 
network, although such a network is not shown separately in Figures 1A and 
1 B. For example, for traffic class 1 , the most preferred bearer types are WLAN 
and UMTS, but GPRS and GSM are also possible choices. The VAS may ob- 

15 tain a home-MBN-specific PBT table in connection with MN registration, or it 
may use a generic default PBT table. 

The traffic management unit TMU considers ail the available infor- 
mation 41 through 43, and creates and updates a Multi-Bearer Routing Table 
MBRT in the traffic distribution unit TDU. The MBRT indicates the IP address 

20 of the appropriate interface unit for each combination of active user w, w+1, 
etc. and traffic class 1 through 5 (the number 5 being just one example). It 
should be noted that a user with multiple simultaneous sessions can have an 
entry for each session in the MBRT table. When the traffic distribution unit 
TDU receives a data packet whose header H indirectly indicates a traffic class 

25 (via a QoS-related parameter), the TDU uses the corresponding user ID and 
the traffic class to retrieve the IP address of the appropriate interface from the 
Multi-Bearer Routing Table MBRT. Next, the TDU encapsulates the data 
packet DP into another data packet DP* whose header H' indicates the IP ad- 
dress (of the selected interface unit) which was retrieved from the MBRT. 

30 When the selected interface unit receives the data packet DP, it decapsulates 
the outer header FT and sends the original data packet DP to the mobile node 
MN. An advantage of an MBRT table substantially as shown in Figure 4 is that 
it directly indicates, for each data packet, the IP address to which the packet is 
to be sent In other words, sending an individual data packet involves no deci- 

35 sion-making, just a retrieval of an IP address from the MBRT table. 
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For IPv6, the traffic class can be mapped to Preference. For IPv4, 
the traffic class can be mapped to Type of Service. If the Differentiated Serv- 
ices protocol is used, traffic class can be mapped to bits reserved for future 
use. According to a preferred embodiment of the invention, for IPv6, all pack- 
5 ets with identical flow labels are usually mapped identically. 

Let us assume that a user w has three simultaneous applications: 
news, FTP and video on demand. The IP packets from the MCN to this user 
may have a preference/priority value of 1 for news, 4 for FTP and 9 for video. 
The PIU and PBT tables are as shown in Figure 4 and the MBN uses five traf- 
10 fic classes, and the mapping between the preference value and the traffic 
class is as follows: 



preference value 


traffic class 


1-2 


1 


3 


2 


4-7 


3 


8-11 


4 


12-15 


5 



In such a case, the IP packets carrying news belong to traffic class 
1, and they are routed via the router whose IP address is IP-GPRSJUa. The 
15 IP packets carrying FTP belong to traffic class 3, and they are routed via the 
router whose IP address is IP-DABJUx. The IP packets carrying video belong 
to traffic class 4, and they are routed via the router whose IP address is IP- 
DABJUx. 

Let us now assume that the user w starts yet another application, 
20 such as e-mail having a preference value of 2. In this case, IP packets carry- 
ing e-mail belong to traffic class 1, and they are routed via the router whose IP 
address is IP-GPRSJUa. 

Figure 5 shows yet another preferred feature or addition to the em- 
bodiment shown in Figure 4. This preferred feature allows paging the mobile 
25 node via a single default bearer and using a single interface unit as long as the 
mobile node is within its coverage area. The feature is based on the idea that 
IP packets separated by a time interval exceeding a certain maximum time 
T^ are treated by the MBN as belonging to two separate sessions. In this 
case, each entry in the MBRT table includes not only the IP address of the 
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relevant interface unit but also a busy flag B and a timer field T. The timer field 
T is compared with the maximum value T^, the value of which is optimized by 
the operator. If the busy flag B is zero, it means that no IP packets used this 
entry for the past time interval of T max . If the busy flag B is set (indicated in Fig- 
5 ure 6 with '8=1'), it means that at least one IP packet used this entry for the 
past time interval of T^. The value of each timer field T is incremented by the 
TMU in a constant time interval. Each time an IP packet is routed by using a 
certain entry in the MBRT table, the corresponding timer field T of that entry is 
reset to zero and the busy flag is set to one. Setting the busy flag to T is pref- 

1 0 erably performed or triggered by the TDU when it routes an IP packet. 

Figure 6 shows a way to use the B and T fields shown in Figure 5. 
In step 61 , the traffic distribution unit TDU examines the header of an incoming 
IP packet. The TDU determines the destination IP address and traffic class 
(direct or indirect mapping) and retrieves the corresponding entry from the 

15 MBRT table. In step 62, the TDU checks the busy flag B to see if the selected 
interface unit IU has been used by this user/session during the last time inter- 
val T^. If not, then in step 63 the TDU begins to buffer incoming IP packets 
and in step 64 the TDU pages the mobile node. More preferably, to reduce the 
computational load of the TDU, the TDU can only trigger a page while the ac- 

20 tual page operation is performed by another unit, such as the TMU. In step 65, 
when the page operation is complete and the mobile node responds, the busy 
flag T is set to one and the timer field T is initialized to zero. In step 66, the 
TDU begins encapsulating each original IP packet with another IP header 
whose destination IP address is retrieved from the MBRT table. Finally, in step 

25 67, the encapsulated IP packets are delivered via the IP routing software to 
the mobile node. 

The traffic management unit TMU is responsible for updating the 
MBRT. The MBRT updating should obey the following principles. An entry of 
the MBRT table, or more specifically, the IP address for a certain combination 

30 of a user/session and a traffic class, can only be modified under the following 
circumstances: If the busy flag B is zero, the IP address can be updated if a) 
the modification is caused by a handover between cells of a broadcast net- 
work or between different networks, b) the mobile node moves out of the cov- 
erage area of one bearer, or c) the traffic load/resource availability changes. 

35 On the other hand, if the busy flag B is zero, the IP address can be updated if 
a) the modification is caused by a handover between cells of a broadcast net- 
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work, b) the mobile node moves out of the coverage area of one bearer, or c) 
there is an extraordinary change of traffic condition. Interruption of IP traffic 
flow should be avoided, if possible. This is particularly important with IP pack- 
ets having high QoS requirements. Inversely, flows with low QoS requirements 
5 should be interrupted first, if interruptions cannot be avoided. Obeying these 
principles allows the use of the same interface unit as long as possible. 

Reference: 

1 . MEMO network documentation at ht tp : / /memo . lboro .ac.uk 
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CLAIMS 

1. A method for sending a data packet (DP), which directly or indi- 
rectly indicates a quality-of-service requirement (QoS). to a mobile node (MN) 
from the mobile node's correspondent node (MCN) via a multi-bearer network, 

5 or MBN, wherein the MBN provides: 

at least one interface unit (IU) to each of multiple alternative bearer 
networks (BN) between the MBN and the mobile node; 

a mobility management function (MMF) to maintain mobility data 
related to the mobile node (MN); 
10 the method being characterized by the steps of: 

selecting an optimal bearer network (BN) for sending a data packet 
(DP) between the MBN and the mobile node (MN) based on: 

the quality-of-service requirement (QoS) of the data packet (DP) in 

question; 

15 traffic load data (41 ) related to the multiple bearers; 

interface unit preference information (PIU. 42); and 
bearer type preference information (PBT, 43). 

2. A method according to claim 1, characterized by combin- 
ing said traffic load data (41), said interface unit preference information (PIU, 

20 42) and said bearer type preference information (PBT, 43) into a data structure 
(MBRT) which functionally corresponds to a two-dimensional table, each entry 
of which directly indicates an interface unit (IU) for a combination of a sub- 
scriber and a quality-of-service requirement (QoS). 

3. A method according to claim 1 or 2, characterized in that 
25 the bearer type preference information (PBT, 43) indicates, at least for some 

values of the quality-of-service requirement, multiple preferred bearers and 
their rank of preference. 

4. A method according to any one of the preceding claims, char- 
acterized in that the interface unit preference information (PIU, 42) indi- 

30 cates, at least for some bearer types, multiple preferred interface units and 
their rank of preference. 

5. A method according to any one of the preceding claims, char- 
acterized in that the bearer type preference information is configurable by 
the operator of the MBN. 
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6. A method according to any one of the preceding claims, char- 
acterized in that said bearer networks (BN) provide at least a first set of 
point-to-point bearers and a second set of multicast or broadcast bearers, and 
the step of sending a data packet comprises sending at least some data pack- 

5 ets encrypted via a bearer of said second set and sending a corresponding 
decryption key to at least one intended recipient via a bearer of said first set. 

7. A method according to claim 2, characterized in that each 
entry of said data structure (MBRT) also indicates whether the entry in ques- 
tion has been used during a predetermined time interval. 

10 8. A network element (VAS) for a multi-bearer network, or MBN, the 

network element comprising a mobility management function (MMF) for a mo- 
bile node (MN), the mobile node communicating with its correspondent node 
(MCN) via the MBN; 

wherein the MBN provides at least one interface unit (IU) to each of 

15 multiple alternative bearer networks (BN) between the MBN and the mobile 
node; 

characterized by: 

a traffic management function (TMF) for selecting an optimal bearer 
network (BN) for a data packet (DP) between the MBN and the mobile node 
20 (MN) based on: 

the quality-of-service requirement (QoS) of the data packet (DP) in 

question; 

traffic load data (41) related to the multiple bearers; 
interface unit preference information (PIU, 42); and 
25 bearer type preference information (PBT, 43). 

9. A network element (VAS) according to claim 8, character- 
ized by being adapted to combine said traffic load data (41), said interface 
unit preference information (PIU, 42) and said bearer type preference informa- 
tion (PBT, 43) into a data structure (MBRT) which functionally corresponds to 
30 a two-dimensional table which directly indicates an interface unit (IU) for each 
combination of a subscriber and a quality-of-service requirement (QoS). 
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